home *** CD-ROM | disk | FTP | other *** search
/ SuperHack / SuperHack CD.bin / Hack / MISC / CHAUMD~1.ZIP / CHAUMD~1.CRY
Encoding:
Text File  |  1996-06-24  |  32.8 KB  |  597 lines

  1. J. Cryptology (1988) 1:65-75
  2.  
  3. The Dining Cryptographers Problem:
  4.  
  5. Unconditional Sender and Recipient Untraceability
  6.  
  7. David Chaum
  8. Centre for Mathematics and Computer Science, Kruislan 413, 1098 SJ 
  9. Amsterdam, The Netherlands
  10.  
  11. Abstract.  Keeping confidential who sends which messages, in a 
  12. world where any physical transmission can be traced to its 
  13. origin, seems impossible. The solution presented here is 
  14. unconditionally or cryptographically secure, depending on whether 
  15. it is based on one-time-use keys or on public keys, respectively. 
  16. It can be adapted to address efficiently a wide variety of 
  17. practical considerations.
  18.  
  19. Key words.  Untraceability, Unconditional Security, Pseudonymity.
  20.  
  21. Introduction
  22.  
  23. Three cryptographers are sitting down to dinner at their favorite 
  24. three-star restaurant. Their waiter informs them that arrangements 
  25. have been made with the maitre d'hotel for the bill to be paid 
  26. anonymously. One of the cryptographers might be paying for the dinner, 
  27. or it might have been NSA (U.S. National Security Agency). The three 
  28. cryptographers respect each other's right to make an anonymous 
  29. payment, but they wonder if NSA is paying. They resolve their 
  30. uncertainty fairly by carrying out the following protocol:
  31.  
  32. Each cryptographer flips an unbiased coin behind his menu, between 
  33. him and the cryptographer on his right, so that only the two of them can 
  34. see the outcome. Each cryptographer then states aloud whether the two 
  35. coins he can see--the one he flipped and the one his left-hand neighbor 
  36. flipped--fell on the same side or on different sides. If one of the 
  37. cryptographers is the payer, he states the opposite of what he sees. An 
  38. odd number of differences uttered at the table indicates that a 
  39. cryptographer is paying; an even number indicates that NSA is paying 
  40. (assuming that the dinner was paid for only once). Yet if a 
  41. cryptographer is paying, neither of the other two learns anything from 
  42. the utterances about which cryptographer it is.
  43.  
  44. To see why the protocol is unconditionally secure if carried out 
  45. faithfully, consider the dilemma of a cryptographer who is not the 
  46. payer and wishes to find out which cryptographer is. (If NSA pays, there 
  47. is no anonymity problem.) There are two cases. In case (1) the two 
  48. coins he sees are the same, one of the other cryptographers said 
  49. "different," and the other one said "same." If the hidden outcome was 
  50. the same as the two outcomes he sees, the cryptographer who said 
  51. "different" is the payer; if the outcome was different, the one who said 
  52. "same" is the payer. But since the hidden coin is fair, both possibilities 
  53. are equally likely. In case (2) the coins he sees are different; if both 
  54. other cryptographers said "different," then the payer is closest to the 
  55. coin that is the same as the hidden coin; if both said "same," then the 
  56. payer is closest to the coin that differs from the hidden coin. Thus, in 
  57. each subcase, a nonpaying cryptographer learns nothing about which of 
  58. the other two is paying.
  59.  
  60. The cryptographers become intrigued with the ability to make 
  61. messages public untraceably. They devise a way to do this at the table 
  62. for a statement of arbitrary length: the basic protocol is repeated over 
  63. and over; when one cryptographer wishes to make a message public, he 
  64. merely begins inverting his statements in those rounds corresponding 
  65. to 1 's in a binary coded version of his message. If he notices that his 
  66. message would collide with some other message, he may for example 
  67. wait a number of rounds chosen at random from a suitable distribution 
  68. before trying to transmit again.
  69.  
  70. 1. Generalizing the Approach
  71.  
  72. During dinner, the cryptographers also consider how any number of 
  73. participants greater than one can carry out a version of the protocol. 
  74. (With two participants, only nonparticipant listeners are unable to 
  75. distinguish between the two potential senders.) Each participant has a 
  76. secret key bit in common with, say, every other participant. Each 
  77. participant outputs the sum, modulo two, of all the key bits he shares, 
  78. and if he wishes to transmit, he inverts his output. If no participant 
  79. transmits, the modulo two sum of the outputs must be zero, since every 
  80. key bit enters exactly twice; if one participant transmits, the sum 
  81. must be one. (In fact, any even number of transmitting participants 
  82. yields zero, and any odd number yields one.) For j rounds, each 
  83. participant could have a j-bit key in common with every other 
  84. participant, and the ith bit of each such key would be used only in the 
  85. ith round. Detected collision of messages leads to attempted 
  86. retransmission as described above; undetected collision results only 
  87. >from an odd number of synchronized identical message segments. 
  88. (Generalization to fields other than GF(2) is possible, but seems to 
  89. offer little practical advantage.)
  90.  
  91. Other generalizations are also considered during dinner. The 
  92. underlying assumptions are first made explicit, including modeling 
  93. key-sharing arrangements as graphs. Next, the model is illustrated 
  94. with some simple examples. The potential for cooperations of 
  95. participants to violate the security of others is then looked at. Finally, 
  96. a proof of security based on systems of linear equations is given.
  97.  
  98. 1.1. Model
  99.  
  100. Each participant is assumed to have two kinds of secret: (a) the keys 
  101. shared with other participants for each round; and (b) the inversion 
  102. used in each round (i.e., a 1 if the participant inverts in that round and a 
  103. 0 if not). Some or all of a participant's secrets may be given to other 
  104. participants in various forms of collusion, discussion of which is 
  105. postponed until Section 1.3. (For simplicity in exposition, the 
  106. possibility of secrets being stolen is ignored throughout.)
  107.  
  108. The remaining information about the system may be described as: (a)
  109. who shares keys with whom; and (b) what each participant outputs
  110. during each round (the modulo two sum of that participant's keys and
  111. inversion). This information need not be secret to ensure
  112. untraceability. If it is publicly known and agreed, it allows various
  113. extensions discussed in Sections 2.5 and 2.6. The sum of all the
  114. outputs will, of course, usually become known to all participants.
  115.  
  116. In the terminology of graphs, each participant corresponds to a 
  117. vertex and each key corresponds to an edge. An edge is incident on the 
  118. vertices corresponding to the pair of participants that shares the 
  119. corresponding key. From here on, the graph and dinner-table 
  120. terminologies will be used interchangeably. Also, without loss of 
  121. generality, it will be assumed that the graph is connected (i.e., that a 
  122. path exists between every pair of vertices), since each connected 
  123. component (i.e., each maximal connected subgraph) could be considered 
  124. a separate untraceable-sender system.
  125.  
  126. An anonymity set seen by a set of keys is the set of vertices in a 
  127. connected component of the graph formed from the original graph by 
  128. removing the edges concerned. Thus a set of keys sees one anonymity 
  129. set for each connected partition induced by removing the keys. The main 
  130. theorem of Section 1.4 is essentially that those having only the public 
  131. information and a set of keys seeing some anonymity set can learn 
  132. nothing about the members of that anonymity set except the overall 
  133. parity of their inversions. Thus, for example, any two participants 
  134. connected by at least one chain of keys unknown to an observer are both 
  135. in the same anonymity set seen by the observer's keys, and the observer 
  136. gains nothing that would help distinguish between their messages.
  137.  
  138. 1.2. Some Examples
  139.  
  140. A few simple consequences of the above model may be illustrative. The 
  141. anonymity set seen by the empty set (i.e., by a nonparticipant observer) 
  142. is the set of all vertices, since the graph is assumed connected and 
  143. remains so after zero edges are removed. Also, the anonymity sets seen 
  144. by the full set of edges are all singleton sets, since each vertex's 
  145. inversion is just the sum of its output and the corresponding key bits.
  146.  
  147. If all other participants cooperate fully against one, of course no 
  148. protocol can keep that singleton's messages untraceable, since 
  149. untraceability exists only among a set of possible actors, and if the set 
  150. has only one member, its messages are traceable. For similar reasons, 
  151. if a participant believes that some subset of other participants will 
  152. fully cooperate against him, there is no need for him to have keys in 
  153. common with them.
  154.  
  155. A biconnected graph (i.e., a graph with at least two vertex-disjoint 
  156. paths between every pair of vertices) has no cut-vertices (i.e., a single 
  157. vertex whose removal partitions the graph into disjoint subgraphs). In 
  158. such a graph, the set of edges incident on a vertex v sees (apart from v) 
  159. one anonymity set containing all other vertices, since there is a path 
  160. not containing v between every pair of vertices, and thus they form a 
  161. connected subgraph excluding v; each participant acting alone learns 
  162. nothing about the contribution of other participants.
  163.  
  164. 1.3. Collusion of Participants
  165.  
  166. Some participants may cooperate by pooling their keys in efforts to 
  167. trace the messages of others; such cooperation will be called collusion. 
  168. For simplicity, the possibilities for multiple collusions or for pooling 
  169. of information other than full edges will be ignored. Colluders who lie 
  170. to each other are only touched on briefly, in Section 2.6.
  171.  
  172. Consider collusion in a complete graph. A vertex is only seen as a 
  173. singleton anonymity set by the collection of all edges incident on it; all 
  174. other participants must supply the key they share with a participant in 
  175. order to determine that participant's inversions. But since a collusion 
  176. of all but one participant can always trace that participant merely by 
  177. pooling its members' inversions as already mentioned, it gains nothing 
  178. more by pooling its keys. The nonsingleton anonymity set seen by all 
  179. edges incident on a colluding set of vertices in a complete graph is the 
  180. set of all other vertices; again, a collusion yields nothing more from 
  181. pooling all its keys than from pooling all its inversions.
  182.  
  183. Now consider noncomplete graphs. A full collusion is a subset of 
  184. participants pooling all of their keys. The pooled keys see each colluder 
  185. as a singleton anonymity set; the colluders completely sacrifice the 
  186. untraceability of their own messages. If a full collusion includes a cut-
  187. set of vertices (i.e., one whose removal partitions the graph), the 
  188. collusion becomes nontrivial because it can learn something about the 
  189. origin of messages originating outside the collusion; the noncolluding 
  190. vertices are partitioned into disjoint subgraphs, which are the 
  191. anonymity sets seen by the pooled keys.
  192.  
  193. Members of a partial collusion pool some but not all of their keys. 
  194. Unlike the members of a full collusion, each member of a partial 
  195. collusion in general has a different set of keys. For it to be nontrivial, 
  196. a partial collusion's pooled keys must include the bridges or separating 
  197. edges of a segregation or splitting of the graph (i.e., those edges whose 
  198. removal would partition the graph). Settings are easily constructed in 
  199. which the pooled keys see anonymity sets that partition the graph and 
  200. yet leave each colluder in a nonsingleton partition seen by any other 
  201. participant. Thus, colluders can join a collusion without having to make 
  202. themselves completely traceable to the collusion's other members.
  203.  
  204. 1.4. Proof of Security
  205.  
  206. Consider, without loss of generality, a single round in which say some 
  207. full collusion knows some set of keys. Remove the edges known to the 
  208. collusion from the key-sharing graph and consider any particular 
  209. connected component C of the remaining graph. The vertices of C thus 
  210. form an anonymity set seen by the pooled keys.
  211.  
  212. Informally, what remains to be shown is that the only thing the 
  213. collusion learns about the members of C is the parity sum of their 
  214. inversions. This is intuitively apparent, since the inversions of the 
  215. members of C are each in effect hidden from the collusion by one or 
  216. more unknown key bits, and only the parity of the sum of these key bits 
  217. is known (to be zero). Thus the inversions are hidden by a one-time pad, 
  218. and only their parity is revealed, because only the parity of the pad is 
  219. known.
  220.  
  221. The setting is formalized as follows: the connected component C is 
  222. comprised of rn vertices and n edges. The incidence matrix M of C is 
  223. defined as usual, with the vertices labeling the rows and the edges 
  224. labeling the columns. Let K, I, and A be stochastic variables defined on 
  225. GF(2)^n, GF(2)^m, and GF(2)^m, respectively, such that
  226. K is uniformly distributed over GF(2)^n, K and I are mutually 
  227. independent, and A = (MK) cross I. In terms of the protocol, K comprises 
  228. the keys corresponding to the edges, I consists of the inversions 
  229. corresponding to the vertices, and A is formed by the outputs of the 
  230. vertices. Notice that the parity of A (i.e., the modulo two sum of its 
  231. components) is always equal to the parity of I, since the columns of M 
  232. each have zero parity. The desired result is essentially that A reveals 
  233. no more information about I than the parity of 1. More formally:
  234.  
  235. Theorem.  Let a be in GF(2)^n. For each i in GF(2)^n, which is assumed by 
  236. I with nonzero probability and which has the same parity as a, the 
  237. conditional probability that A = a given that I = i is 2^(1 - m). Hence, 
  238. the conditional probability that I = i given that A = a is the a priori 
  239. probability that I = i.
  240.  
  241. Proof.  Let i be an element of GF(2)^n have the same parity as a. 
  242. Consider the system of linear equations (MK) cross i = a, in k an 
  243. element of GF(2)^n. Since the columns of M each have even parity, as 
  244. mentioned above, its rows are linearly dependent over GF(2)^m. But as a 
  245. consequence of the connectedness of the graph, every proper subset of 
  246. rows of M is linearly independent. Thus, the rank of M is m - 1, and so 
  247. each vector with zero parity can be written as a linear combination of 
  248. the columns of M. This implies that the system is solvable because i 
  249. cross a has even parity. Since the set of n column vectors of M has rank 
  250. m - 1, the system has exactly 2^(n - m + 1) solutions.
  251.  
  252. Together with the fact that K and I are mutually independent and 
  253. that K is uniformly distributed, the theorem follows easily.                           
  254.  
  255. 2. Some Practical Considerations
  256.  
  257. After dinner, while discussing how they can continue to make 
  258. untraceable statements from this respective homes, the cryptographers 
  259. take up a variety of other topics. In particular, they consider different 
  260. ways to establish the needed keys; debate adapting the approach to 
  261. various kinds of communication networks; examine the traditional 
  262. problems of secrecy and authentication in the context of a system that 
  263. can provide essentially optimal untraceability; address denial of 
  264. service caused by malicious and devious participants; and propose 
  265. means to discourage socially undesirable messages from being sent.
  266.  
  267. 2.1. Establishing Keys
  268.  
  269. One way to provide the keys needed for longer messages is for one 
  270. member of each pair to toss many coins in advance. Two identical 
  271. copies of the resulting bits are made, say each on a separate optical 
  272. disk. Supplying one such disk (which today can hold on the order of 
  273. 10^10 bits) to a partner provides enough key bits to allow people to 
  274. type messages at full speed for years. If participants are not 
  275. transmitting all the time, the keys can be made to last even longer by 
  276. using a substantially slower rate when no message is being sent; the 
  277. full rate would be invoked automatically only when a 1 bit indicated 
  278. the beginning of a message. (This can also reduce the bandwidth 
  279. requirements discussed in Section 2.2.)
  280.  
  281. Another possibility is for a pair to establish a short key and use a 
  282. cryptographic pseudorandom-sequence generator to expand it as needed. 
  283. Of course this system might be broken if the generator were broken. 
  284. Cryptanalysis may be made more difficult, however, by lack of access 
  285. to the output of individual generators. Even when the cryptographers do 
  286. not exchange keys at dinner, they can safely do so later using a public-
  287. key distribution system (first proposed by [4] and [3]).
  288.  
  289. 2.2 Underlying Communication Techniques
  290.  
  291. A variety of underlying communication networks can be used, and their 
  292. topology need not be related to that of the key-sharing graph.
  293.  
  294. Communication systems based on simple cycles, called rings, are 
  295. common in local area networks. In a typical ring, each node receives 
  296. each bit and passes it round-robin to the next node. This technology is 
  297. readily adapted to the present protocols. Consider a single-bit message 
  298. like the "I paid" message originally sent at the dinner table. Each 
  299. participant exclusive-or's the bit he receives with his own output 
  300. before forwarding it to the next participant. When the bit has traveled 
  301. full circle, it is the exclusive-or sum of all the participants' outputs, 
  302. which is the desired result of the protocol. To provide these messages 
  303. to all participants, each bit is sent around a second time by the 
  304. participant at the end of the loop.
  305.  
  306. Such an adapted ring requires, on average, a fourfold increase in 
  307. bandwidth over the obvious traceable protocols in which messages 
  308. travel only halfway around on average before being taken off the ring by 
  309. their recipients. Rings differ from the dinner table in that several bit-
  310. transmission delays may be required before all the outputs of a 
  311. particular round are known to all participants; collisions are detected 
  312. only after such delays.
  313.  
  314. Efficient use of many other practical communication techniques 
  315. requires participants to group output bits into blocks. For example, in 
  316. high-capacity broadcast systems, such as those based on coaxial cable, 
  317. surface radio, or satellites, more efficient use of channel capacity is 
  318. obtained by grouping a participant's contribution into a block about the 
  319. size of a single message (see, e.g., [5]). Use of such communication 
  320. techniques could require an increase in bandwidth on the order of the 
  321. number of participants.
  322.  
  323. In a network with one message per block, the well-known contention 
  324. protocols can be used: time is divided evenly into frames; a participant 
  325. transmits a block during one frame; if the block was garbled by 
  326. collision (presumably with another transmitted block), the participant 
  327. waits a number of frames chosen at random from some distribution 
  328. before attempting to retransmit; the participants' waiting intervals 
  329. may be adjusted on the basis of the collision rate and possibly of other 
  330. heuristics [5].
  331.  
  332. In a network with many messages per block, a first block may be 
  333. used by various anonymous senders to request a "slot reservation" in a 
  334. second block. A simple scheme would be for each anonymous sender to 
  335. invert one randomly selected bit in the first block for each slot they 
  336. wish to reserve in the second block. After the result of the first block 
  337. becomes known, the participant who caused the ith 1 bit in the first 
  338. block sends in the ith slot of the second block.
  339.  
  340. 2.3. Example Key-Sharing Graphs
  341.  
  342. In large systems it may be desirable to use fewer than the m(m - 1)/2 
  343. keys required by a complete graph. If the graph is merely a cycle, then 
  344. individuals acting alone learn nothing, but any two colluders can 
  345. partition the graph, perhaps fully compromising a participant 
  346. immediately between them. Such a topology might nevertheless be 
  347. adequate in an application in which nearby participants are not likely 
  348. to collude against one another.
  349.  
  350. A different topology assumes the existence of a subset of 
  351. participants who each participant believes are sufficiently unlikely to 
  352. collude, such as participants with conflicting interests. This subset 
  353. constitutes a fully connected subgraph, and the other participants each 
  354. share a key with every member of it. Every participant is then 
  355. untraceable among all the others, unless all members of the completely 
  356. connected subset cooperate. (Such a situation is mentioned again in 
  357. Section 3.)
  358.  
  359. If many people wish to participate in an untraceable communication 
  360. system, hierarchical arrangements may offer further economy of keys. 
  361. Consider an example in which a representative from each local fully 
  362. connected subgraph is also a member of the fully connected central 
  363. subgraph. The nonrepresentative members of a local subgraph provide 
  364. the sum of their outputs to their representative. Representatives would 
  365. then add their own contributions before providing the sum to the 
  366. central subgraph. Only a local subgraph's representative, or a collusion 
  367. of representatives from all other local subgraphs, can recognize 
  368. messages as coming from the local subgraph. A collusion comprising 
  369. the representative and all but one nonrepresentative member of a local 
  370. subgraph is needed for messages to be recognized as coming from the 
  371. remaining member.
  372.  
  373. 2.4. Secrecy and Authentication
  374.  
  375. What about the usual cryptologic problems of secrecy and 
  376. authentication?
  377.  
  378. A cryptographer can ensure the secrecy of an anonymous message by 
  379. encrypting the message with the intended recipient's public key. (The 
  380. message should include a hundred or so random bits to foil attempts to 
  381. confirm a guess at its content [1].) The sender can even keep the 
  382. identity of the intended recipient secret by leaving it to each recipient 
  383. to try to decrypt every message. Alternatively, a prearranged prefix 
  384. could be attached to each message so that the recipient need only 
  385. decrypt messages with recognized prefixes. To keep even the 
  386. multiplicity of a prefix's use from being revealed, a different prefix 
  387. might be used each time. New prefixes could be agreed in advance, 
  388. generated cryptographically as needed, or supplied in earlier messages.
  389.  
  390. Authentication is also quite useful in systems without identification.
  391. Even though the messages are untraceable, they might still bear
  392. digital signatures corresponding to public-key "digital pseudonyms"
  393. [1]; only the untraceable owner of such a pseudonym would be able to
  394. sign subsequent messages with it. Secure payment protocols have
  395. elsewhere been proposed in which the payer and/or the payee might be
  396. untraceable [2]. Other protocols have been proposed that allow
  397. individuals known only by pseudonyms to transfer securely information
  398. about themselves between organizations [2]. All these systems require
  399. solutions to the sender untraceability problem, such as the solution
  400. presented here, if they are to protect the unlinkability of pseudonyms
  401. used to conduct transactions from home.
  402.  
  403. 2.5. Disruption
  404.  
  405. Another question is how to stop participants who, accidentally or even 
  406. intentionally, disrupt the system by preventing others from sending 
  407. messages. In a sense, this problem has no solution, since any 
  408. participant can send messages continuously, thereby clogging the 
  409. channel. But nondisupters can ultimately stop disruption in a system 
  410. meeting the following requirements: (1) the key-sharing graph is 
  411. publicly agreed on; (2) each participant's outputs are publicly agreed on 
  412. in such a way that participants cannot change their output for a round 
  413. on the basis of other participants' outputs for that round; and (3) some 
  414. rounds contain inversions that would not compromise the 
  415. untraceability of any nondisrupter.
  416.  
  417. The first requirement has already been mentioned in Section 1.1, 
  418. where it was said that this information need not be secret; now it is 
  419. required that this information actually be made known to all 
  420. participants and that the participants agree on it.
  421.  
  422. The second requirement is in part that disrupters be unable (at least 
  423. with some significant probability) to change their output after hearing 
  424. other participants' outputs. Some actual channels would automatically 
  425. ensure this, such as broadcast systems in which all broadcasts are 
  426. made simultaneously on different frequencies. The remainder of the 
  427. second requirement, that the outputs be publicly agreed on, might also 
  428. be met by broadcasting. Having only channels that do not provide it 
  429. automatically, an effective way to meet the full second requirement 
  430. would be for participants to "commit" to their outputs before making 
  431. them. One way to do this is for participants to make public and agree on 
  432. some (possibly compressing and hierarchical, see Section 2.6) one-way 
  433. function of their outputs, before the outputs are made public.
  434.  
  435. The third requirement is that at least some rounds can be contested 
  436. (i.e., that all inversions can be made public) without compromising the 
  437. untraceability of non-disrupting senders. The feasibility of this will be 
  438. demonstrated here by a simple example protocol based on the slot 
  439. reservation technique already described in Section 2.2.
  440.  
  441. Suppose that each participant is always to make a single reservation 
  442. in each reserving block, whether or not he actually intends to send a 
  443. message. (Notice that, because of the "birthday paradox," the number of 
  444. bits per reserving block must be quadratic in the number of 
  445. participants.) A disrupted reserving block would then with very high 
  446. probability have Hamming weight unequal to the number of participants. 
  447. All bits of such a disrupted reserving block could be contested without 
  448. loss of untraceability for nondisrupters.
  449.  
  450. The reserved blocks can also be made to have such safely contestable
  451. bits if participants send trap messages. To lay a trap, a participant
  452. first chooses the index of a bit in some reserving block, a random
  453. message, and a secret key. Then the trapper makes public an
  454. encryption, using the secret key, of both the bit index and the random
  455. message. Later, the trapper reserves by inverting in the round
  456. corresponding to the bit index, and sends the random message in the
  457. resulting reserved slot. If a disrupter is unlucky enough to have
  458. damaged a trap message, then release of the secret key by the trapper
  459. would cause at least one bit of the reserved slot to be contested.
  460.  
  461. With the three requirements satisfied, it remains to be shown how 
  462. if enough disrupted rounds are contested, the disrupters will be 
  463. excluded from the network.
  464.  
  465. Consider first the case of a single participant's mail computer 
  466. disrupting the network. If it tells the truth about contested key bits it 
  467. shares (or lies about an even number of bits), the disrupter implicates 
  468. itself, because its contribution to the sum is unequal to the sum of 
  469. these bits (apart from any allowed inversion). If, on the other hand, the 
  470. single disrupter lies about some odd number of shared bits, the values 
  471. it claims will differ from those claimed for the same shared bits by 
  472. the other participants sharing them. The disrupter thereby casts 
  473. suspicion on all participants, including itself, that share the disputed 
  474. bits. (It may be difficult for a disrupter to cast substantial suspicion 
  475. on a large set of participants, since all the disputed bits will be in 
  476. common with the disrupter.) Notice, however, that participants who 
  477. have been falsely accused will know that they have been--and by 
  478. whom--and should at least refuse to share bits with the disrupter in 
  479. the future.
  480.  
  481. Even with colluding multiple disrupters, at least one inversion must 
  482. be revealed as illegitimate or at least one key bit disputed, since the 
  483. parity of the outputs does not correspond to the number of legitimate 
  484. inversions. The result of such a contested round will be the removal of 
  485. at least one edge or at least one vertex from the agreed graph. Thus, if 
  486. every disruptive action has a nonzero probability of being contested, 
  487. only a bounded amount of disruption is possible before the disrupters 
  488. share no keys with anyone in the network, or before they are revealed, 
  489. and are in either case excluded from the network.
  490.  
  491. The extension presented next can demonstrate the true value of 
  492. disputed bits, and hence allows direct incrimination of disrupters.
  493.  
  494. 2.6. Tracing by Consent
  495.  
  496. Antisocial use of a network can be deterred if the cooperation of most 
  497. participants makes it possible, albeit expensive, to trace any message. 
  498. If, for example, a threatening message is sent, a court might order all 
  499. participants to reveal their shared key bits for a round of the message. 
  500. The sender of the offending message might try to spread the blame, 
  501. however, by lying about some odd number of shared bits. Digital 
  502. signatures can be used to stop such blame-spreading altogether. In 
  503. principle, each party sharing a key could insist on a signature, made by 
  504. the other party sharing, for the value. of each shared bit.
  505.  
  506. Such signatures would allow for contested rounds to be fully resolved,
  507. for accused senders to exonerate themselves, and even for colluders to
  508. convince each other that they are pooling true keys.  Unfortunately,
  509. cooperating participants able to trace a message to its sender could
  510. convince others of the message's origin by revealing the sender's own
  511. signatures. A variation can prevent a participant's signatures from
  512. being used against him in this way: instead of each member of a pair
  513. of participants signing the same shared key bit, each signs a separate
  514. bit, such that the sum of the signed bits is the actual shared key
  515. bit. Signatures on such "split" key bits would still be useful in
  516. resolving contested rounds, since if one contester of a bit shows a
  517. signature made by the second contester, then the second would have to
  518. reveal the corresponding signature made by the first or be thought to
  519. be a disrupter.
  520.  
  521. In many applications it may be impractical to obtain a separate 
  522. signature on every key bit or split key bit. The overhead involved could 
  523. be greatly reduced, however, by digitally signing cryptographic 
  524. compressions of large numbers of key bits. This might of course require 
  525. that a whole block of key bits be exposed in showing a signature, but 
  526. such blocks could be padded with cryptographically generated 
  527. pseudorandom (or truly random) bits, to allow the exposure of fewer 
  528. bits per signature. The number of bits and amount of time required to 
  529. verify a signature for a single bit can be reduced further by using a 
  530. rooted tree in which each node is the one-way compression function of 
  531. all its direct descendants; only a digital signature of each participant's 
  532. root need be agreed on before use of the keys comprising the leaves.
  533.  
  534. 3. Relation to Previous Work
  535.  
  536. There is another multiparty-secure sender-untraceability protocol in 
  537. the literature [1]. To facilitate comparison, it will be called a mix-net 
  538. here, while the protocol of the present work is called a dc-net. The 
  539. mix-net approach relies on the security of a true public-key system 
  540. (and possibly also of a conventional cryptosystem), and is thus at best 
  541. computationally secure; the dc-net approach can use unconditional 
  542. secrecy channels to provide an unconditionally secure untraceable-
  543. sender system, or can use public-key distribution to provide a 
  544. computationally secure system (as described in Section 2.1).
  545.  
  546. Under some trust assumptions and channel limitations, however, 
  547. mix-nets can operate where dc-nets cannot. Suppose that a subset of 
  548. participants is trusted by every other participant not to collude and 
  549. that the bandwidth of at least some participants' channels to the 
  550. trusted subset is incapable of handling the total message traffic. Then 
  551. mix-nets may operate quite satisfactorily, but dc-nets will be unable 
  552. to protect fully each participant's untraceability. Mix-nets can also 
  553. provide recipient untraceability in this communication environment, 
  554. even though there is insufficient bandwidth for use of the broadcast 
  555. approach (mentioned in Section 2.4).
  556.  
  557. If optimal protection against collusion is to be provided and the 
  558. crypto-security of mix-nets is acceptable, a choice between mix-nets 
  559. and dc-nets may depend on the nature of the traffic. With a mail-like 
  560. system that requires only periodic deliveries, and where the average 
  561. number of messages per interval is relatively large, mix-nets may be 
  562. suitable. When messages must be delivered continually and there is no 
  563. time for batching large numbers of them, dc-nets appear preferable.
  564.  
  565. 4. Conclusion
  566.  
  567. This solution to the dining cryptographers problem demonstrates that
  568. unconditional secrecy channels can be used to construct an
  569. unconditional sender-untraceability channel. It also shows that a
  570. public-key distribution system can be used to construct a
  571. computationally secure sender-untraceability channel. The approach
  572. appears able to satisfy a wide range of practical concerns.
  573.  
  574. Acknowledgments
  575.  
  576. I am pleased to thank Jurjen Bos, Gilles Brassard, Jan-Hendrik Evertse, 
  577. and the untraceable referees for all their help in revising this article. 
  578. It is also a pleasure to thank, as in the original version that was 
  579. distributed at Crypto 84, Whitfield Diffie, Ron Rivest, and Gus Simmons 
  580. for some stimulating dinner-table conversations.
  581.  
  582. References
  583.  
  584. [1]    Chaum, D., Untraceable Electronic Mail, Return Addresses, and 
  585. Digital Pseudonyms, Communications of the  ACM, vol. 24, no. 2, 
  586. February 1981, pp. 84-88.
  587. [2]    Chaum, D., Security Without Identification: Transaction Systems 
  588. to Make Big Brother Obsolete, Communications of the ACM, vol. 28, 
  589. no. 10, October 1985, pp. 1030-1044.
  590. [3]    Diffie, W., and Hellman, M.E., New Directions in Cryptography, IEEE 
  591. Transactions on Information Theory, vol. 22, no. 6, November 1976, 
  592. pp. 644-654.
  593. [4]    Merkle, R.C., Secure Communication over Insecure Channels, 
  594. Communications of the ACM, vol. 21, no. 4, 1978, pp. 294-299.
  595. [5]    Tanenbaum, A.S., Computer Networks, Prentice Hall, Englewood 
  596. Cliffs, New Jersey, 1981.
  597.